1. Field of Invention
The invention relates to network communication technologies and, more specifically, to mechanisms that enable IPv4 clients to communicate over an IPv6 network.
2. Discussion of Related Art
Computer networks allow computers and potentially any associated users to communicate electronically throughout the globe over a worldwide amalgamation of networks often referred to as the Internet. A common network protocol used to communicate over the Internet is called the Internet Protocol or “IP” for short. There are a number of different versions of IP including the common IP version 4 (herein also referred to as “IPv4”) and the more recently-developed IP version 6 (herein also referred to as “IPv6”). Although IP is used on the Internet, it can be used in a variety of network contexts. IP is also often employed within local networks to connect computers.
In order for one computing system to communicate with another computing system over a particular network, it is important that each computing system be uniquely identified on that network. IPv4 provides a 32 bit addressing mechanism, which should allow for 232 or approximately 4 billion different addresses. Practical considerations limit the number of IPv4 addresses to approximately 2 or 3 billion. While this may seem like an unlimited supply of addresses, the proliferation of the Internet and network devices throughout the globe have pushed or exceeded these address limits.
As the pool of available IPv4 addresses has shrunk, various systems have developed to allow multiple computers or devices to share a single external (i.e., directly accessible from the Internet) IP address. One such system is called “Network Address Translation.” A Network Address Translation device (also known as a “Network Address Translator” or a “NAT”) separates out a number of computing systems in a private network from the rest of the Internet. All computing systems on the Internet that are not in such a private network are required to have a unique IP address that is unique as compared to all other Internet-connected computing systems that are also not behind a NAT. The computing systems in each private network generally have an address that is unique to that private network, but not necessarily to the global Internet. The NAT then translates that private address into a globally unique IP address on the fly as each packet exits the private network through the NAT and into the global Internet. NATs typically alter packets using TCP and UDP port mapping to enable two-way traffic between external hosts and internal clients.
Accordingly, the NAT uses a limited number (potentially just one) globally unique address that it exposes to the Internet, while allowing the network devices that are behind the NAT to have a larger number of private network addresses that need not be globally unique throughout the Internet. The use of NATs therefore allows for a short term solution to the problem of there being a relatively limited number of IPv4 addresses available. Accordingly, IPv4 computing systems and NATs often work together.
Certain address blocks are reserved under IPv4 for NAT-internal use only. For example, the address blocks 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12 are all defined in RFC 1918 (entitled “Address Allocation for Private Internets”) as reserved for “Private Internets.” Generally, a NAT device routes packets to and from a reserved “private” IP address to a world-accessible “public” IP address.
IPv6, on the other hand, has a 128-bit addressing mechanism, which is sufficient to provide unique addresses for well into the anticipated future. Accordingly, the problem associated with a limited number of unique addresses under IPv4 may be addressed by reconfiguring the Internet to operate exclusively under IPv6 instead. Such a reconfiguration will likely occur over an extended period of time because there is significant infrastructural investment in the current Internet that is based on the IPv4 protocol. Furthermore, there is no one governing entity that controls the entire Internet. Accordingly, it is commonly accepted that the Internet needs to concurrently work with both IPv6 and IPv4, at least for the near future. In order to facilitate robust communication over the Internet, mechanisms have been developed that allow for IPv4 computing systems to communicate with IPv6 computing systems.
One mechanism often referred to as the “6to4” mechanism uses IPv6 packets as payload of IPv4 packets. When transitioning from an IPv4 network to an IPv6 network, the IPv6 packet is extracted and transmitted. When transitioning from an IPv6 network to an IPv4 network, the IPv6 packet is included as the payload of an IPv4 packet, and then the IPv4 packet is transmitted. Several problems exist with this 6to4 mechanism. Specifically, it may not work well when the IPv4 computing system that is to communicate is behind a NAT. Many NATs are not programmed to allow the transmission of arbitrary payload types. Accordingly, NATs may not permit communication of a payload in the form of an IPv6 packet. Even when the NAT permits such communication, the local address within the private network cannot be used in a 6to4 scheme. The 6to4 mechanism will work with a NAT if the NAT and 6to4 router are in the same physical box. However, there are many cases in which the NAT may not be easily upgradeable to include a 6to4 routing function.
“Teredo” is another protocol for transporting packets between nodes that support only IPv4 and nodes that support IPv6. Teredo is described in more detail in RFC 4380 (entitled “Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)”). Teredo encapsulates IPv6 packets within IPv4 UDP datagrams, which most NATs can forward properly. Thus, IPv6-aware hosts behind NATs can be used as Teredo tunnel endpoints even when they don't have a dedicated public IPv4 address.
The Teredo implementation usually involves a client, a relay, and a server, although a relay is not always necessary. The Teredo client is a device on an IPv6 network. The client is assigned a unique IPv6 address that starts with a specific reserved prefix (2001:0000::/32).
A Teredo relay connects clients on an IPv6 network with an IPv4 network. The relay advertises a route to the Teredo IPv6 prefix to other IPv6 hosts in order to receive traffic from those hosts addressed to any Teredo client. The relay then forwards received packets a UDP datagram within an IPv4 packet. The relay also receives packets from Teredo clients addressed to native IPv6 hosts over UDP/IPv4 and forwards those packets into the native IPv6 network.
A Teredo server is used by a Teredo client both to determine whether the client is behind a NAT (and if so, to determine the type of NAT), and also to “punch holes” in the NAT so that the NAT will allow incoming traffic and forward it to the correct client. “Hole punching” involves initiating a connection from a host behind a NAT to a host external to the NAT so that the NAT will subsequently forward packets received from that external host back to the internal host. Some of the various types of NATs are described below.
A NAT needs to transmit packets both from an internal client to the external destination and in the opposite direction to facilitate communication. Accordingly, it needs some way to identify and match packets received from the outside with specific internal hosts. This is generally accomplished using port mapping. Port mapping can either be manually configured on the NAT, or can occur automatically. There are several different types of NATs that are commonly in use that can be categorized in terms of the system they use for port mapping. These definitions are set out in RFC 3489 (entitled “STUN—Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)”).
In the case of a “full cone” NAT, also known as “one-to-one” NAT, all requests that originate from the same internal IP address and port are mapped to the same external IP address and port. An external host can send a packet to the internal host by sending a packet to the mapped external address. For example, if the internal client has a local IP address of 192.168.1.5, and it attempts to connect to a web server on the Internet operating on port 80, the full cone NAT could modify the packet so the source IP address is the external IP address of the NAT device, for example, 151.207.245.67, and the source port could be mapped, usually to some unprivileged port, for example, 2000.
A “restricted cone” NAT is similar to a “full cone” NAT inasmuch as all internal requests from the same host to the same port number are mapped to the same external IP address and source port. Restricted cone NATs have the additional limitation that only external systems that have previously been sent packets are permitted to connect to the internal system. Thus, before an external system can connect to a client within the NAT, the client must have first initiated communication with that external system.
A “port restricted cone” NAT is similar to a “restricted cone” NAT with the additional limitation that external systems can only connect to clients within the NAT on the same port that the internal client used to connect to the external system.
Finally, in a “symmetric” NAT, all requests from the same internal IP address and port to a specific external destination IP address and port are mapped to a unique external source IP address and port. If the same internal client sends a packet with the same source address and port to a different destination, a different port mapping is used. Only an external host that receives a packet can send a packet back to the internal host.
For the purposes of this application, a “restricted” NAT is any NAT other than a full cone NAT.
Some NATs support a behavior called “hairpinning.” Hairpinning is a mechanism that allows two endpoints on the internal side of a NAT to communicate even if they only use each other's external IP addresses and port numbers.
Some NATs support a protocol called “UPnP” or “Universal Plug and Play.” UPnP supports zero-configuration networking and automatic discovery, whereby a device can dynamically join a network, obtain an IP address, announce its name, convey its capabilities upon request, and learn about the presence and capabilities of other devices. In particular, clients connected to a UPnP-enabled NAT can use UPnP to discover, add, edit, or delete port mappings.
For NATs that will not allow an inbound connection through to an internal client before that internal client has first initiated an outbound connection, the technique of “hole punching” may be used by the internal client as an indirect way of instructing the NAT to forward inbound packets. Hole punching often involves a server other than the two clients that are attempting to communicate. For example, a Teredo client may establish a connection with a known Teredo server. The client may continuously send “bubble” packets to the server so that the NAT will forward packets from the server back to the client. If bubble packets are not sent, the port mappings on the client NAT may timeout, thereby not permitting further communications from the Teredo Server. If a second Teredo client, outside the NAT, needs to connect to the first Teredo client inside the NAT but packets from the second client cannot penetrate the NAT to reach the first client because of the NAT port-mapping behavior (as described above), the second client may be able to contact the Teredo server which in turn will send a message to the first client concerning the connection attempt. The first client can then send a bubble message to the second client. Depending on how the NAT is configured, it might then allow packets from the second client to be forwarded back to the first client.
IPv6 also provides mechanisms for a nodes on a network to discover each other's presence, to determine each other's link-layer addresses, and find routers and maintain reachability information about the paths to active neighbors. Many of these mechanisms are described in RFC 2461 (entitled “Neighbor Discovery for IP Version 6 (IPv6)”). In particular, a “Neighbor Solicitation” or “NS” message is sent by an IPv6 node to determine the link-layer address of a neighbor, or to verify that a neighbor is still reachable via a cached link-layer address. A “Neighbor Advertisement” or “NA” message is sent in response to a Neighbor Solicitation message. A node may also send unsolicited Neighbor Advertisement messages to announce a link-layer address change.